DOCUMENT RESUME 



BD 262 404 



CS 209 253 



PUB TYPE 



EDRS PRICE 
DESCRIPTORS 



AUTHOR Soderston, Candace 

TITLE Task Analysis: Applying Composition Theory in an 

Industrial Forum. 
PUB DATE 84 

NOTE 5p.; In: Proceedings ot the International Technical 

Communication Conference of the Society for Technical 
Communication (31st, Seattle, WA, April 29-May 2, 
1984). p89-92. 

Reports - Descriptive (141) — Speeches/Conference 
Papers (150) 

MFOl/PCOl Plus Postage. 

*6roup Dynamics; ^Organizational Communication; 
^Prewriting; Revision (Written Composition); *Task 
Analysis; ^Technical Writing; ^Writing Exerci^ses; 
Writing Processes 
IDENTIFIERS ^Audience Awareness; Group Projects 

ABSTRACT 

Technical writers involved in an institutional 
writing project need some way of viewing the raw material globally 
before writing. In this way they can build a framework which can be 
used for different types of information. This is accomplished through 
a task analysis meeting that highlights the following preparatory 
steps prior to writing: (1) determine the scope, (2) define the 
audience and identify the reader, (3) determine the purpose, (4) 
determine the task or tasks, and (5) determine the constraints — posed 
by the system or by how the document will be used. The purpose of the 
task analysis meeting is, therefore, to elicit from the subject 
matter experts information that is procedurally and user oriented. 
The goal of the meeting is to have participants generate tasks that 
fit into four columns: action, audience, information requirements, 
and result. The information generated in this collective exercise is 
more comprehensive than what can be extracted through individual 
interviews. Performing this type of task analysis before writing a 
single word may make the difference between designer-based material 
and usable, reader-based material. (HOD) 
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With this advice from both our traditional writing teachers 
and leade.^ within the field of composition reseaJh we aTe 
aware of the great importance of the very early pS^ tJ! 
wntuig process. Faced with the, constraints of rS 

Son i;?.-"""'', °' "^^^^ ^° """"^'^ to 

iruition in a discrete planning stage? 



.nTZ'n ''"'""'P""."'^"- ^'^""S'l'Ccnstsha^lL preaching 

•^'""Por once of a pre-writing stage for decades. Uorerecemly 

^"f research has shewn, halihhprepa^^^^ 

J«^m,nan, of document quality. Within industry we a^akinrZl of 

'^y'Mcserecommendaticns,oourrnod7cToper<^t?n^^^ 

''"fy''''"'''-''S<'Cnepar,icu,arlyeffecti,eandeW^^^^^ 

ZlZ^l^^cTu^r''''''^^^^^^^ 

TI'^TheorelicalRathnaUforaPre-witlngStaieln Composing 

As writing teachers have been asserting over the past 
<i«ades. the crucial first step in any writing project is 
Preparation. This preparation is usually broken down, in an 
«tcmpt to move from the abstract to the concrete, info 
.srec mam substeps: identifying the reader, establishing the 
"jective. and determining the scope of the writing 
*«'gnraent. 

2°Citr""^ Linda Flower, a leader within the field of 
«4 2 i^"/h" University, has 

pros '.oI'h' ""P^'f" of transforming writer-based 
?«> 2h?^ '^"''^^ writer-based 

«»v br S M P"f'''="y'=o'nprchcnsible to its author, it 
*Pno,V-.*"M/ ^o i«s intended audience. I don't 

^Pose It Will tax most of us in the field of technical 
--'municatun to understand why this could be so. 

Jitter based prose, with its egocentric focus, its narrative 
^ "zation and its survey structure, lacks the primary 
r^«'cnt that contributes to the attribute "usability." That 
§^lt T^^^^'^ organized around the reader's needs and 
^ somehow, in this situation, the writer neglected to 
m,\4. and to write mth this person 's objective in 
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The Real Link Between Preparation and Usable Documents 

Faced with the inevitable shortness of time and, if we are 
lucky, a wealth of writer-based (read "designer-based") raw 
matenal, w- are in constant danger of neglecting these 
cardinal concerns when drafting our documents. Production 
deadlines and current operating procedures may lead some 
wnters to conclude, regretfully, that the best they can do is 
LT??"^?. Pf ^'^'^^o^'f f"'"=«ion: that is. gather the source 
matenal. stitch it together here and there with appropriate 
transitions. poUsh this sentence, and clear up that syntactic 
ambiguity. The result of this labor is a writer-based 
document with a survey structure, but at least, we writers 
can proudly assert, we've presented a comprehensiye survey. 
If the readers hunt through our material long enough with 
tenacity, we are sure they will be able to find every piece of 
information that they could ever possibly need. 
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Unfonunately, this type of document structure is not usable 
since it is not organized around the reader's needs and goals. 

Bond, Hayes, and Flower, doing research for the Document 
Design Center in Washington, D,C,, studied the processes 
that s,tveral writers went through to revise writer-based legal 
documents into reader-based material.(2) They found that 
the best revisions were produced by those writers who read 
tht-ough the entire document before making any changes. 
These writers went on to massively reorganize the material, 
while the others simply poiishcxi sentences here and there to 
improve the existent flow. 

Similarly, when we are not revising, but instead are creating 
a document, we need some way of viewing the material 
globally before writing. In this way we can build the 
framework into which to insert each piece of information. 



Though this meeting is labeled a "task analysis" because 
determining the tasks or tasks is the primary focus, you will 
see shortly that this structure actually encompasses all the 
preparatory steps. 



The Task Analysis Meeting as Preparation for Writing 



Given sufficient time, good technical writers can, witnout 
other institutionalized structures, sift the reader-based 
wheat from the designer-based chaff. By studying the 
technical source material, by painfully but steadily 
processing it through our own gray matter, by learning the 
characteristics of our users, and by individually tracking 
down and interviewing the appropriate developers, we can 
determine the appropriate structure for our documents. 
Seldom, however, do we have enough time allotted to do 
superb work given this methodology. 

Our professional challenge, therefore, is to streamline our 
processes, to most quickly, efficiently, and produciively 
manage the time available in order to transform the mass of 
designer-based raw material into an organized, high quality, 
reader-based flow. 

The remainder of this paper describes such a streamlined 
process, the Task Analysis Meeting. This meeting is an 
institutionalized forum for accomplishing what we know to 
be the all-important preparatory steps in any writing 
assignment. Hearkening back to our writing teachers' words 
of wisdom and using the Document Design Ccpver's 
expansion upon the preparation stage, prior to writing we 
should do the following: 

1 . Determine the scope 

2. Define the audience (identify the reader) 

3. Define the purpose (establish the objective) 

4. Determine the task or tasks 

5. Determine the constraints (posed by the system or by 
how the document will be used). 



A Scenario of a Task Analysis Meeting 



Robert Ward has outlined the general steps involved in 
analyzing task structure. As we know, we human beings 
Icara best by example. Most of us, therefore, provide 
abundant scenarios in our literature, in order to aid our 
readers. In the jargon from Carnegie Mellon, we 
'instantiate" oar scenarios for our readers. In plain T^n g l fyft ^ 
and in the spirit of a good technical communicator, I'd likt 
to provide you with a concrete example, a case study of thii 
proposed information development forum, the task-analy^ 
meeting. 

I'm drawing this example from my experience last summer 
as a writer on a special project at IBM in Kingston, N.Y. 
Robert Ward set up and presided overt task-analysis 
meeting that took place before I set pen to paper or, mora 
accurately, before I set finger to keyboatd. ThJ reason I CM 
hold this experience up to the light is because it was tn 
acclaimed success. Moreover, there was no new 
development effort necessary for this project, no newcodt 
needed to be written; the project involved documentatioo 
alone. 

Let me qualify myself at this point and make it clear thai* 
while the output of the project was documentation, the 
success of the project did not rest upon publications 
personnel alone. Many people were critical to the project 
including product designers, developers, and testers. TM 
task analysis alone would not have been suffic/ent loto^U^ 
the quality of the documentation, but it was the crucial 
step. This important first step was followed by usability 
walkthroughs, human factors testing, technical revicwf,«i^ 
hands-on use of the documentation in the Systems Test 
laboratory.(4) This paper, however, will focus upon tb» 
first step, preparation, and its rde cannot be miniiniicd. 

For this task analysis meeting. Ward reserved a confcreac* 
room for three hours and invited representatives from 
Product Usability, Product Design/Development, Quiliiy 
Assurance, Systems Test, and Publications. Dcpcndinx^ 
upon the nature of your project, you might want to iocWt 
others such as field engineers, service engineers, and 
marketing representatives. 
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The Explicit Purpose of (he T»A Anaiytl* Meeiint 

TVpicaUy. the raw soutce material for any new product or 
function .s wntten by experts on the subject matter. The 
matenal .s organized around the internal structure of the 
product or function and is not written to explain its use or 
««rea to promote understanding. This makes scns^Ts nce the 
pnme function of the person doing this writing is toTX 

leurrtTcUT"?"'" designer is. anHaT 

better be. focused on the simplicity and elegance of the 
internal structure. 

Teaching someone how to «^^the product is an entirely 
different concern, however. The purpose of the 
task-analysis meeting is. therefore, to elicit from the subject 
SliVef '"f°™ation that is procedurally and user 

^l"*'?"*"^ """'^ °f t° the ten of us 

present and outlined our tasks for the day. On a nip chart 

to right were the following: 



Action 
Audience 

Information Requirements 
Result 



•mi; ^"yi""'"*'"^ "Wmally be another column but 
environment and it was not a variable. 



We were to generate, in the proper sequential order, all of 
the tasks that our users would have to perform in order to 
use this new capacity. For each task we would then identify 
who exactly in our typical consumer's company would be 
performing the task, what infinnat .a that person would 
require in order to perform the task, and what results we 
expected upon completion of the task. 

For example, in this initial meeting, we concluded that there 
were ten major tasks involved in this procedure. Task 
number 2 was planning and included planning for hardware 
configuration and software customization. The targeted 
audiences were the hardware administrator and two 
software system administrators. These titles implied, of 
course, a certam educational and experientiaJ background. 
The information required was a list of sequential steps 
needed to make a particular connection. The result we 
expected upon completion of this task was a list of logical 
addresses and station addresses to pass on to the person 
performing the next task. 

Just to give you an idea of the range of tasks and audiences 
involved m this project, task number 6 was logging on to a 
word processing product. Our targeted audience was a text 
operator, such as a secretary. This operator would require 
the log-on procedure and information on correcting the 
typical errors that could occur during the log-on process. 
The result we expected upon completion of this task was 
that the operator could edit text files. 

As the group generated this information. Ward wrote it all 
down on the flip chart. As Peter Elbow asserts, the act of 
writing, the visual feedback we derive from the words we 
place on the page, actually helps us to pinpoint the gaps in 
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Task 2: Planning 



'1 



Action 


Audience 


Information Requirements 


Result 


Hardware 
Plannini 


Administrator 


Description of hardware 
rcquirciDcnts for both 
systems 


Hardware plan 
describing terminal 
locations, telephone 
lines, modems, diagram 
of physical addresses 


System A 
Software 
Planning 


System A 
Software 
Administrator 


Description of System A's 
requirements for the 
connection 


List of logical addresses 
and station addresses 
for use by System B's 
Admipistrator 


System B 
Software 
Planning 


System B 
Software 
Administrator 


Description of System B's 
requirements for the 
connection 

List of addresses from 
System A's Administrator 


System B 
Configuration 
Worksheet for use in 
next task 



our thinking and to identify the directions in which we want 
to go.(5) The visual feedback from the flip chart helped us 
in our attempt to generate thorough and sequential material. 

As in the cliche "the whole is greater than the sum of its 
parts," the information generated in this collective exercise 
was more comprehensive than we couki have extracted 
through individual interviews. Moreover, not only was the 
information more comprehensive, but our use of time was 
mtfcA more efficient. 

The success of the meeting depends on the writers* ability to 
extract procedural information from the developers. I recall 
asking questions out of my ignorance that slowed the pace 
of the meeting. These questions, however, resulted in 
concrete, step-by-step, procedural information, rather than 
an abstract overview that could inaccurately assume too 
much of the user. Ignorance is actually a blessing at this 
point in the process because it fo'xes the writer to approach 
the material from the outside, from the perspective of a 
novice user. 

Summary: The Importance of Task Analysis 

In closing, why should we bother with task analysis or, more 
importantly, why should we care to produce reader-based 
material? Coming from the outside in, the consumer's first 
contact with our products is usually through our 
documentation. As we know, first impressions are 
extremely resistant to change so, unless we have a captive 
market, we can ill afford to create a negative first 
impression. It is doubtful whether the consumer can 
distinguish between product usability and document 
usability and, therefore, non reader-based literature could be 
severely damaging. Performing this type of task analysis 
before writing a single word, satisfying the prescriptions of 
writing theorists, may make the difference between 
designer-based material and usable, reader-based material. 
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